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SYSTEMS AND METHODS FOR MANAGING ELECTRONIC 
COMMUNICATIONS USING TOKEN INFORMATION TO ADJUST 

ACCESS RIGHTS 

CROSS-REFERENCE TO RELATED APPLICATIONS 
[0001] This application is related to U.S. Provisional Application Serial 
No. 60/247,990, filed November 14, 2000, from which priority is claimed. 

BACKGROUND OF THE INVENTION 

1. Field of Invention 

[0002] This invention relates to managing electronic communications. 

2. Description of Related Art 

[0003] Currently, there are various devices and systems that handle calls and 
provide greeting messages to callers. These conventional devices and systems include 
various answering machines, voice mail systems, and interactive voice response (IVR) 
systems. Typically, when a called party is busy or after a predetermined number of 
rings, a message is played to a caller indicating that the called party is currently 
unavailable. However, the greeting message that is played to the caller usually is only 
a general message that is the same for all callers. 

SUMMARY OF THE INVENTION 
[0004] Although conventional technology is an improvement over manually 
taking messages, it still would be highly desirable to provide more useful/personalized 
information to callers. For instance, it would be desirable to provide alternative ways 
to reach the called party (e.g., by cell phone, pager). 

[0005] One difficulty in providing such information to callers is that the 
called party may not want to give out private information to everyone who calls. For 
example, a called party probably wouldn't want to provide pager access to a 
telemarketer. On the other hand, the called party might want to provide such access to 
a friend, family member or business associate. 

[0006] It would be highly desirable to select interaction information so that 
the privacy of the called party is protected. At the same time, it would be highly 
desirable that any selection criteria not be too rigid. For instance, the called party 
might wish to provide interaction information only on a temporary basis to a person, 
such as, for example, to a building contractor working on a home improvement 
project. 



[0007] This invention provides various methods and systems for managing 
electronic commimications using token information. In various exemplary 
embodiments of the systems and methods of this invention more useful/personalized 
information is provided to a caller. Furthermore, a token may be issued for a caller 
usable to temporarily adjust at least one selection criterion for providing information. 
In this manner, the caller may be provided with access to a "higher level" of 
interaction information than would be the case without the token. 

[0008] In various exemplary embodiments, an interaction manager provides 
interaction information that may be provided as an interaction space displayed or 
otherwise presented on a web-enabled device, such as, for example, a web-enabled 
telephone. Furthermore, the interaction manager may process and/or issue the above- 
mentioned tokens. 

[0009] In various other or additional exemplary embodiments, the 
interaction space may include one or more of visibility information that informs a 
caller about the status of a callee, accessibility information that provides the caller 
with a list of communication channels available to the caller, and continuity 
information that includes information and action facilitation data that reflect the 
ongoing interaction between the caller and the callee. In various other or additional 
exemplary embodiments, the interaction manager may determine a response message 
for a caller at least in part based on the relation of the caller and the callee and the 
current status of the callee. 

[0010] These and other features and advantages of this invention are 
described in, or are apparent from, the detailed description of various embodiments of 
the systems and methods according to this invention. 

RRTEF DESCRIPTION OF THE DRAWINGS 

[0011] Various exemplary embodiments of this invention are described in 
detail with reference to the following figures, where like numerals reference like 
elements, and wherein: 

[0012] Fig. 1 is a block diagram of one exemplary embodiment of a system 
that manages electronic conununications using token information to adjust access 
rights; 

[0013] Fig. 2 is an exemplary diagram of an interaction space; 



[0014] Figs. 3 and 4 show two exemplary communication devices 
illustrating the use of interaction spaces according to this invention; 

[0015] Fig. 5 is a diagram of an exemplary screen input for issuing access 

tokens; 

[0016] Fig. 6 is a diagram of an exemplary data structure representing an 
access token; 

[0017] Fig. 7 is a diagram of an exemplary database record containing caller 
information; 

[0018] Fig. 8 is an exemplary block diagram of the interaction manager 
shown in Fig. 1 ; and 

[0019] Fig. 9 is a flowchart outlining an exemplary technique for using 
token information to adjust access rights according to this invention. 

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 

[0020] Interaction information may be provided to specific persons based on 
various selection criteria. Moreover, it may become desirable to adjust the access 
rights of a particular person. An access token may be issued that can be used to adjust 
at least one selection criterion usable to determine the kind and/or amount of 
information to be provided to a caller. 

[0021] Fig. 1 is a block diagram of one exemplary embodiment of a 
system 100 that manages electronic communications using token information to adjust 
access rights. The electronic communication system 100 includes one or more 
commvmication devices, such as the commxmication device 130, and one or more 
interaction managers, such as the interaction manager 180. All of the above 
components are coupled together via a communication infrastructure 150 through 
links, such as the links 140 and 160. 

[0022] The communication infrastructure 150 can accommodate 
communication between the communication device 130 and the interaction manager 
180 by providing a conmiunication path capable of transmitting and receiving 
conmiunication signals over the links 140 and 160. The communication 
infrastructure 150 can include any known or later developed network for transmitting 
information. Such networks can include any combination of one or more wide area 
networks, one or more local area networks, one or more public switched telephone 
networks, one or more wireless or wired networks, one or more intranets, the Internet 



and/or any other distributed processing network or system. In general, the 
communication infrastructure 150 can be any known or later developed combination 
of systems, computer programs or structures usable to transmit and receive 
information over the links 140 and 160. 

[0023] The links 140 and 160 can be any known or later developed device or 
system for transmitting data among the conomunication devices 130 and 150 and the 
interaction manager 180. Such devices include direct serial/parallel cable 
connections, satellite links, wireless links, connections over a wide area network or a 
local area network, connections over a public switched telephone system, connections 
over an intranet, connections over the Intemet and/or connections over any other 
distributed processing network or system. Additionally, the links 140 and 160 can be 
software devices linking various software systems. In general, the links 140 and 160 
can be any known or later developed devices or systems, computer programs or 
structures usable to connect the communication device 130 and the interaction 
manager 180 to the commimication infrastructure 150. 

[0024] In various exemplary embodiments, the communication device 130 
can be a web-enabled telephone (a webphone), a cellular telephone, a standard 
telephone, a personal digital assistant ("PDA"), a two-way pager, a facsimile machine 
or program, or a network-attached personal computer. The interaction manager 1 80 
provides a communication device 130 with a response message. In most cases, this 
response message will be implemented as an interaction space. Fig. 2 shows one 
exemplary embodiment of an interaction space according to this invention. 

[0025] Various exemplary embodiments of an interaction manager 1 80 used 
in conjunction with this invention are disclosed in U.S. Patent Application Serial No. 
09/794,102, filed February 28, 2001, which is incorporated herein by reference in its 
entirety. 

[0026] The interaction manager 1 80 is capable of providing a caller 1 1 0 
associated with at least one communication device 130 with a set of one or more 
communication channels usable to interact with a callee 190, along with information 
about the current status of the callee 190. The caller 1 10 can then make an informed 
choice regarding which provided commimication channel to use to contact the callee 
1 90, based on the interpretation by the caller 1 10 of the status of the callee 190. The 
list of communication channels can include hypertext links, for example, pointing to 
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addresses of other communication devices and/or to locations capable of directing 
communications to these devices. 

[0027] The interaction manager 1 80 is able to generate one or more 
personalized interaction spaces such as the interaction space 200 as shown in Fig. 2. 
5 A single interaction space 200 reflects the relationship between a callee 190, who is 
the owner of the interaction space 200, and a caller 110 who uses the interaction 
space 200. In various exemplary embodiments of the methods and systems of this 
invention, the interaction manager 180 is implemented as a distributed system having 
software components residing on a web server. These software components interact 
1 0 with other individuals, or with other interaction managers that reside on one or more 
web servers. 

[0028] Fig. 2 is a block diagram graphically illustrating one exemplary 
embodiment of the interaction space 200 according to this invention. As shown in 
Fig. 2, the interaction space 200 includes visibility information 210, accessibility 

1 5 information 220, and continuity information 230. The visibility information 2 1 0 
informs a caller 1 10 about the status or situation of a callee 190. The accessibility 
information 220 provides the caller 110 with a list of communication channels that the 
callee 190 has decided to make available to the caller 110, The continuity 
information 230, for example, can contain information and action facilitation data that 

20 reflect the ongoing interaction between that caller 1 10 and the callee 190. However, it 
should be appreciated that the interaction space 200 does not necessarily need to 
include the continuity information 230. 

[0029] The interaction space 200 is presented to the caller in a modality that 
is suited to the particular communication device 130 being used by the caller 110. In 

25 various exemplary embodiments, the interaction space 200 is generated by integrating 
the visibility information 210, the accessibility information 220, and the continuity 
information 230. 

[0030] Generally, a caller 110 associated with the communication device 
130 can interact with or obtain interaction information about a caller 1 10 associated 
30 with the interaction manager 1 80. For example, a caller 1 1 0, using a webphone, may 
connect with a callee 190 associated with interaction manager 180. In this case, the 
communication infrastructure 150 can include the Internet. Once the caller 1 10 
connects with the interaction manager 180 of the callee 190, various information can 
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be provided to the caller 110. In particular, the interaction manager 180 can display 
an interaction space, such as the interaction space 200 shown in Fig. 2. 

[003 1] Depending on the relation between the caller 1 1 0 and the callee 1 90, 
and the current status of the callee 190, the interaction manager 180 can provide 
personalized information to the caller 110, such as a set of links to various 
communication devices associated with the callee 190. For example, the interaction 
manager 180 may provide links to one or more of a webphone, a telephone, a pager , a 
facsimile device, an electronic mail (e-mail) system, and/or a scheduler system. In 
addition, the interaction manager 180 may provide information as to the availability of 
the callee 190, such as, for example, a mess^e indicating that the callee 190 is tied up 
m an important meeting. However, the information that is displayed or otherwise 
presented via the interaction manager 1 80 may be based upon a predefined 
relationship between the caller 1 10 and the callee 190. That is, the callee 190 may 
wish to only provide certain information, such as, for example, the callee's home 
telephone number, to a certain group of persons who have been identified as fiiends of 
the callee 190. 

[0032] The mteraction manager 1 80 is capable of determining the identity of 
the caller 1 10 associated with a commvinication device 130 using various identifying 
technologies, such as automatic number identification (ANI), a cookie file, and 
various biometric devices, such as, for example, a fingerprint recognition device, an 
iris scan device, or any other known or later developed biometric device. Once the 
identity of the caller 1 10 has been determined, the interaction manager 180 can 
determine the appropriate information that the caller 1 10 is entitled to access. 

[0033] However, the interaction manager 1 80 can adjust these selection 
criteria if an access token is associated with the caller. An access token may be issued 
by the interaction manager 180 or by another device or system, such as, for example, 
by an access token issuance screen 500 shown in Fig. 5. The access token may be 
encrypted and/or contain authenticating information. The access token may either be 
included in an interaction request received by the interaction manager 180 or obtained 
separately from another data source. 

[0034] The interaction manager 1 80 can determine the appropriate 
interaction information for the caller 1 10 based on the usual selection criteria and then 
adjust the amount of mformation provided to the caller using the access token. For 
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example, the caller 110 may not have been registered as a friend of the callee 100 in 
the interaction manager 180. Therefore, this caller 110 might not be entitled to 
receive links to the callee's 110 pager and home telephone number. However, if an 
access token is associated with this caller 110, the interaction manager 1 80 may raise 
5 the access level from a "low" level to a "high" level, for example. Once the access 
level has been adjusted, the interaction manager 180 can allow the caller 1 10 to 
receive a greater degree of information about the callee 190 than would have been the 
case without the token. Furthermore, the interaction manager 180 can check the 
access token for an expiration date and only adjust the one or more selection criterion 

10 if the access token has not yet expired. 

[0035] Figs. 3 and 4 show two exemplary devices capable of displaying the 
interaction space 200 to a caller 1 10 or to a callee 190. Although each communication 
device is capable of displaying the interaction space 200 to any caller 1 10, or to the 
callee 190, the actual content of the interaction space 200 may, and generally will, 

1 5 differ depending on the identity of a particular caller 110. For example, as shown in 
Fig, 3, the interaction space 200 displayed on the first communication device 301 
includes a general message that the callee 190 can provide to any caller 110. 
However, as shown in Fig. 4, the interaction space 200 displayed on the second 
communication device 302 includes an interaction space 200 that is specifically 

20 tailored to a particular caller 110, and provides information having a greater degree of 
detail and specificity. Because the interaction space 200 displayed on the second 
communication device 302 can be customized for a particular caller 110, the 
interaction space 200 displayed on the second communication device 302 can enhance 
the interaction between that caller 110 and the callee 190. 

25 [0036] In various exemplary embodiments, such as that shown in Fig. 4, for 

example, the interaction space 200 can include links to available communication 
channels a particular caller 1 10 is permitted to access. For example, these available 
communication channels can be grouped into or represented entirely as logical 
interaction channels based on the situation and needs of a particular caller 110, 

30 However, the set of communication channels available to a caller 110 may depend on 
the status of the callee 190. For example, the callee 190 may not allow any direct 
calls when the callee 190 is in a meeting. 
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[0037] Fig. 5 shows an exemplary embodiment of an access token issuance 
screen 500 usable by the callee 190 to issue access tokens for various callers 1 10, or, 
alternatively, to associate access tokens with various callers 1 10. The exemplary 
access token issuance screen 500 has a caller highlight selection menu 510 usable to 
5 select a caller 110 who will be the recipient of, or associated with, a particular issued 
token, an access level highlight selection menu 520 usable to select an access level, 
and an expiration text input box 530 usable to input an expiration date of the access 
token. It should be noted that a user can, and usually, but not always, will be required 
to select one entry from each highUght selection menu 510 and 520 and the text input 
10 box 530. 

[0038] In an exemplary mode of operation, the access token issuance 
screen 500 can accept an identifier associated with a caller 110. As shown in Fig. 5, 
the user has highlighted the entry for "Sal's Roofing Company" from the caller 
highlight selection menu 510. Furthermore, this user has selected "high" from the 

15 access level selection menu 520, and has entered an expiration date value in text input 
box 530. Once the appropriate information has been entered into the access token 
issuance screen 500, the information can be used to create an access token for the 
indicated caller 110. In this example, the access token would be issued to, or 
associated with, Sal's Roofing Company with an access level of high and an expiration 

20 date of February 15, 2001. Thus, a caller 110 identified as being from Sal's Roofing 
Company would have the highest access level to receive interaction information from 
the callee 190 until the expiration ending date has occurred. 

[0039] While the exemplary access token issuance screen 500 uses several 
selection menus and a text input box, it should be appreciated that the selection of 

25 various parameters such as the caller identity, access level, and the token expiration 
date can be accommodated using a variety of devices such as a number of graphical 
user interface selection widgets, check boxes, buttons, list boxes, pop-up or drop- 
down marks, text entry boxes and/or the like, or any other known or later developed 
interfaces that an operator can access. It should also be appreciated that the access 

30 token issuance screen 500 can also, or alternatively, include any device capable of 
receiving or defining token information such as a command line interface, a touch 
sensitive display, a keyboard, or a number of mechanical selection devices such as 
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buttons and knobs, or the like, without departing from the spirit and scope of this 
invention. 

[0040] Fig. 6 shows an exemplary embodiment of a data structure 600 
corresponding to an access token. The exemplary data structure 600 includes a caller 
5 ID field 610, a callee ID field 620, an access level field 630, and an expiration date 
field 640. In particular, the caller ID stored in the caller ID field 610 may be a URL 
associated with the caller 1 10 or the telephone number associated with the caller 110, 
for example. Likewise, the callee ID stored in the callee ID field 620 may be a URL 
associated with the callee 190 or the telephone number associated with the callee 190. 

10 Furthermore, the access level stored in the access level field 630 can include a code or 
other indicator specifying the access level to which the caller 1 10 is to be given. 
Finally, the expiration date stored in the expiration date field 640 may include a date 
on which the access token expires. This expiration date stored in the expiration date 
field 640 may include not only the particular day on which the expiration occurs, but 

1 5 also a particular hour/minute/second during the day when the access token is to 

expire. Furthermore, it should be appreciated that the format of the expiration date 
stored in the expiration date field 640 may be represented in any known or later 
developed format for representing such information. 

[0041] Furthermore, it should be appreciated that the access token 600 can 

20 be stored in a database or other file system, stored on a magnetic card that can be read 
by a suitable magnetic card reader, printed on a suitable medium such as paper, 
printed as a bar code readable by a bar code reader or scanner, and the like. In 
general, the form in which the access token information stored in the exemplary data 
structure 600 is embodied can vary as a design choice without departing from the 

25 spirit and scope of this invention. 

[0042] In operation, the access token issuance screen 500, as illustrated in 
Fig. 5, can generate the access token using information entered by the callee 190. For 
example, the callee 190 might select Sal's Roofing Company from the caller highlight 
selection menu 510, and an appropriate identifier associated with the selected caller 

30 may be generated and stored in the caller ID field 610. Furthermore, the callee 

ID stored in the callee ID field 620 can be generated fi-om an identifier associated with 
the interaction manager 180 of that callee 190. In addition, the access level data 
stored in the access level field 630 can be generated from the access level selected in 
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the level selection highlight menu 520 and the expiration date stored in the expiration 
date field 640 can be generated from the expiration date data entered into text input 
box 530. 

[0043] Fig. 7 shows an exemplary database 700 usable to store information 
5 regarding a plurality of known callers 110. The exemplary database 700 includes a 
plurality of records 705. Each record 705 includes a type 710 that stores data 
indicating the type of identifier, an identifier field 720 that stores data identifying the 
caller, a name field 730 that stores data storing the caller's name, a relation field 740 
that stores data defining the relationship between the caller 110 and the callee 190, 
1 0 and a level field 750 that stores data indicating the current access level of the caller 
110, 

[0044] In various exemplary embodiments, the database 700 can be a 
database implemented using a single database management system (DBMS) managed 
by a controller residing on a memory such as a hard disk. However, it should be 

1 5 appreciated that this database 700 can be implemented on one or more separate 
computer systems. For example, the database 700 could reside on a separate 
computer system and/or a server having a relational database capable of executing 
SQL instructions. Furthermore, the database 700 can be stored in a database situated 
in the communication device 130. It should be appreciated that other information may 

20 be stored in various databases, or may be derivable firom stored information, or made 
available firom external sources, to determine the access rights of a particular caller 
110. 

[0045] Fig, 8 is a block diagram of one exemplary embodiment of a circuit 
or software program that implements the interaction manager 180. As shown in 

25 Fig. 8, the exemplary interaction manager 180 includes a controller 810, a 

memory 820, a local input/output mterface 830, a database 840, a token generator 850 
and a network input/output interface 860. The controller 810 can be linked to the 
other devices 820-860 by a data control bus 815. 

[0046] In a first mode of operation, the controller 810 receives an interaction 

30 request via the network input/output 860 and stores this information in the 

memory 820. Once the interaction request has been stored, the controller 810 then 
determines an identifier associated with the interaction request. The identifier can be 
extracted firom the interaction request or, alternatively, can be obtained via external 
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information stored outside the interaction manager 1 80. For example^ the 
controller 810 may interact with an automatic number identification (ANI) system to 
obtain a caller ID associated with the caller 110. Alternately, the identifier may either 
be extracted firom a cookie file that has been associated with the caller's webphone or 
5 that has been passed along with the interaction request. 

[0047] Once the controller 810 has determined the identity of the caller 1 1 0, 
the controller 810 can then determine the interaction information to be provided to 
this caller 110. The controller 810 can query the database 840 for information relating 
to the caller 1 10, using the caller identifier. For example, the database 840 may be a 

10 relational database in which information relating to callers is stored in tables or 
records, such as the database 700 illustrated in Fig. 7. Furthermore, the caller 
identifier may serve as a key or index value to one or more of such tables or records. 

[0048] The database 840 can include a variety of information usable by the 
interaction manager 180 to determine and create an appropriate interaction space 200 

1 5 for the caller. For example, the caller 110 may be a fi^iend of the callee 190. In this 
case, the callee 190 may have included information in database 840 identifying 
the caller 1 10 as a fi*iend. If the caller 1 10 is identified as a friend in the database 840, 
the controller 810 can provide an appropriate level of information to the caller 1 10 via 
local input/output interface 830. 

20 [0049] The controller 810 may also use other information to make an 

appropriate decision for providing interaction information. For example, the 
controller 810 may access the database 840 and/or obtain fiirther information that the 
callee 190 is currently in an important meeting. For example, the controller 810 may 
query via the local input/output interface 830 a calendar or scheduler system 

25 associated with the callee 190 to determine the present availability of the callee 190. 

The scheduler or calendar information might show that the callee 190 is currently in a 
meeting. 

[0050] For example, the controller 810 might determine that the status of the 
meeting is of high importance based on the social context of the meeting or data 
30 stored in the calendar or scheduler system. For instance, the meeting as shown in the 
calendar information might be taking place in the Board Room. Thus, the 
controller 810 might determine that this meeting is of very high importance to the 
callee 190. Consequently, the controller 810 might limit the amount of interaction 



12 

information to be provided to most callers 110 during the time interval when this 
meeting is taking place. Thus, the controller 810 might only provide a general 
message as to the unavailability of the callee 190 for the duration of the meeting. 
However, the callee 1 90 might provide his or her pager number to a particular caller 
5 110 who is of high priority. This might be accomplished by causing the token 

generator 850 to issue an appropriate token for, or associate an appropriate token with, 
that caller 1 10 to override the usual selection criteria. 

[0051] If the database 840 does not have an entry for a caller 1 10, a generic 
interaction space may be displayed or otherwise presented to that caller 110. For 

10 example, that caller 1 10 may not be acquainted with the callee 1 90 and therefore there 
might not be any information in database 840 regarding this caller 110. Since there is 
no preexisting relationship between this caller 110 and the callee 190, a low level of 
access may be granted to this caller 110. 

[0052] Prior to determining the interaction space 200 for a particular caller 

15 1 1 0 or providing other types of interaction information to the caller 110, the 

controller 810 may examine the interaction request stored in the memory 820 for 
token information. If token information is found for this caller 110, the controller 810 
can adjust the level of access of this caller 1 10 based on the token information. 

[0053] The database 840 may indicate information sufficient to only provide 

20 a minimal amount of information to a particular caller 110. However, token 

information associated with this caller 110 may cause the information provided to this 
caller 1 10 to be increased (or decreased). In this case, the token information will 
cause at least one selection criterion to be adjusted. For example, this caller 110 may 
be a contractor associated with the callee 190 who is working on a home-improvement 

25 project for the callee 1 90. Although the callee 1 90 might not ordinarily wish to 

provide personal information to this caller 1 10, it might be desirable to provide some 
otherwise private interaction information to the contractor for the dxaration of the 
project. The controller 810 can check the token information for an expiration date and 
only adjust the one or more of the selection criteria if the expiration date has not 

30 occurred. 

[0054] In various exemplary embodiments, the controller 810 is a general 
purpose computer. However, in other exemplary embodiments, the controller 810 can 
be a special purpose computer, a microprocessor or microcontroller, an ASIC or other 
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integrated circuit, a digital signal processor, a hard-wired electronic or logic circuit 
such as a discrete element circuit, a programmable logic device such as a PLD, PLA, 
FPGA or PAL, or the like, without departing ftom the spirit and scope of the 
invention. 

[0055] The memory 820 of the exemplary embodiment can be implemented 
using static or dynamic RAM. However, the memory 820 can also be implemented 
using a floppy disk and disk drive, a writable optical disk and disk drive, a hard disk 
drive, flash memory or the like, without departing from the spirit and scope of this 
invention. Furthermore, the memory 820 can be a persistent memory, i.e., maintain 
information when external power is removed, or the memory 820 can be a volatile 
memory, i.e., information is lost when power is removed. 

[0056] In various exemplary embodiments, the local input/output 
interface 830 and/or the network input/output interface 860 can be hard-wired 
interfaces. However, in other exemplary embodiments, the local input/output 
interface 830 and/or the network input/output interface 860 can be any device suitable 
to transmit information to and from another device, such as a universal asynchronous 
receiver/transmitter (UART), a local area network (LAN), a wide area network 
(WAN), a parallel digital interface, a software interface or any combination of known 
or later developed software and hardware. While the local input/output interface 830 
and the network input/output interface 860 are depicted as separate devices in Fig. 8, 
it should be appreciated that the input and output fimctions can be accommodated 
either by a single device or by separate devices without departing from the spirit and 
scope of this invention. 

[0057] hi various exemplary embodiments, the database 840 can be 
implemented using a single database management system (DBMS) managed by the 
controller 810 residing on a memory such as a hard disk. However, it should be 
appreciated that the database 840 can be implemented on one or more separate 
computer systems. For example, the database 840 can reside on a separate computer 
system and/or a server having a relational database capable of executing SQL 
instructions. 

[0058] The exemplary local input/output interface 830 can include a 
software module capable of generating hypertext markup language (HTML) code to 
provide screen output capable of being viewed over the Internet by a caller having a 
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suitable Web browser (e.g., Microsoft Internet Explorer, Netscape 
Navigator/Communicator). However, it should be appreciated that the local 
input/output interface 830 can produce an audio report which can be played to the 
caller^ for example, over the telephone. Furthermore, it should be appreciated that any 
5 type of knovm or later developed output generation devices can be used to provide 

information to a caller, such as an electromechanical printing device, various displays 
and the like, without departing from the spirit and scope of the present invention. 

[0059] Fig. 9 is a flowchart outlining one exemplary embodiment of a 
technique for adjusting access rights of a caller according to this invention. Beginning 

10 at step S700, control continues to step S710, where an interaction request is received 
by the callee's interaction manager. The interaction request may include information 
relating to the caller's identity, the caller's communication device and/or the caller's 
mode of communication. In this exemplary embodiment, a caller may contact the 
callee's interaction manager using a Web-enabled telephone (a web phone) and the 

1 5 callee's interaction manager can be resident on a hypertext transfer protocol (HTTP) 
server. Next, in step S720, selection criteria relating to the caller are retrieved from at 
least one data source. The interaction request may include identification information 
extracted from a cookie file associated with the caller's web phone, for example. In 
this case, the selection criteria for the caller may be determined using this identifier. 

20 The selection criteria for the caller may also involve determining the callee's present 
status. For example, the selection criteria of information to be provided to the caller 
can be affected by the current status of the callee. For instance, the callee may be tied 
up in an important meeting and as such may not wish to provide any interaction 
information to callers at the present moment. The callee's interaction manager can 

25 determine the callee's status in various ways using numerous sources of information. 

For example, the callee's status may be determined using information derived from an 
electronic scheduler/calendar system, data explicitly input by the callee, sensor 
information, location information, and social context information. 

[0060] Furthermore, the selection criteria may also involve determining 

30 whether the caller is known to the callee. For example, this may be determined by 
examining a list of known caller IDs. If the caller identifier does not match 
information stored in these lists of known caller IDs, it may be determined that the 
caller and the callee do not know each other. Regardless of how the relationship is 
determined, based on the determined relationship, one of any number of different 
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message types that reflect the determined relationship can be generated. Once the 
pertinent selection criteria for the caller has been retrieved, control continues to step 
S730. hi step S730, a determination is made as to whether any access token exists for 
the caller. The token may be stored along with the interaction request or it may be 
5 stored separately. An indicator that the token exists may be stored in the callee's 
interaction manager, for example, 

[0061] Token information may be extracted either from the interaction 
request or may be determined in some other manner from other data sources. The 
token information may represent a numerical value which can be encrypted or 

10 otherwise encoded. The token itself may contain authenticating information which 
can be used to ensure that the token is genuine. Once the token information is 
extracted, control continues to step S750 where one or more selection criterion are 
modified. In step S750, the interaction manager can adjust the selection criteria based 
on the contents of the token. For example, the caller may be a contractor for whom 

1 5 the callee is using on a home-improvement project. Furthermore, the token 

information may indicate that the caller should have a "high level" of access during 
the next week when the project is tmderway. In this case, although the selection 
criteria retrieved by the interaction manager may indicate a veiy low level of access 
for this caller, nonetheless the interaction manager may increase the access level for 

20 this particular caller based on the token information that is extracted. Once the 

relevant one or more selection criterion has been adjusted, control continues to step 
S760, where the operation stops. 

[0062] Various exemplary embodiments of the systems and methods of this 
invention can be implemented using a general purpose computer system. However, 

25 the systems and methods of this invention cmi be implemented using any number of 

one or more programmed general purpose computers, programmed microprocessors or 
micro-controllers and peripheral integrated circuit elements, ASIC or other integrated 
circuits, digital signal processors, hard-wired electronic or logic circuits such as 
discrete element circuits, programmable logic devices such as a PLD, PLA, FPGA or 

30 PAL, or the like. In general, any device capable of implementing a finite state 

machine that is in turn capable of implementing the flowchart shown in Fig. 9 and/or 
the interaction manager shown in Figs. 1 and/or 8, can be used to implement the 
systems and methods of this invention. 
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[0063] While this invention has been described in conjunction with the 
various exemplary embodiments outlined above, it is evident that many alternatives, 
modifications and variations will be apparent to those skilled in the art. Accordingly, 
the exemplary embodiments of the invention, as set forth above, are intended to be 
illustrative, not limiting, various changes may be made without departing from the 
spirit and scope of the invention. 



